The present invention relates generally to data processing using transaction processing in which changes to a database are recorded in an audit file to provide recovery of the database in the face of a failure. More particularly, the invention is directed to a method of providing automatic transaction capability to programs not configured for transaction processing.
Real world commerce involves transactions. A transaction may involve some commercial activity, such as a deposit to a bank account, or a transfer of funds from one bank account or another, or a sale of a product. In order to maintain a record of the transaction, it will be recorded in a database, preferably in a consistent manner. For example, a transfer of funds from one account to another will require a database change that will reduce the one account by the amount of the transfer, and augment the other account by that same amount. If the change is effected properly, the database change is kept consistent. If, however, a failure occurs during the change, there is a question of whether the entire transaction was recorded, i.e., if the database was changed to reflect the reduction of one account, was the database also changed to reflect the increase of the other account.
To ensure that the database remains accurate after the changes/modifications, the paradigm of transaction processing was developed. A transaction itself is often defined as an explicitly delimited operation or set of operations that change or otherwise modify the content of a database from one consistent state to another. Changes or modifications are treated as a single unit in that all changes/modifications of a transaction are formed and made permanent (i.e., the transaction is “committed”), or none of the changes are made permanent (the transaction is “aborted”). Failure occurring during the execution of a transaction will result in the transaction being aborted, and whatever changes were made to a database are undone to return it to a consistent state. A transaction, then, is said to guarantee Atomicity, Consistency, Isolation, and Durability.
Before a transaction commits its changes to the database, audit information about the database change/modification is written to a so-called “audit log” (or “audit trail”). At a conceptual level, an audit log can be viewed as a history of changes to a database, and information from the audit log will allow the database to redo or undo update operations as required. The audit log information may also be used to reconstruct the database in the event of a catastrophic event that corrupts or otherwise destroys the database.
Databases that ate managed with transactions have some inherent advantages. Updates to the database are permanently recorded in the audit file on magnetic media. This permits the database manager to:
Recover files that are lost when a database storage device is permanently damaged,
Create and maintain a duplicate copy of the database in a remote location, and
Improve performance by eliminating I/O operations that can be recovered (in the event of a failure) from the audit log.
In order to use transactions, an application program must be able to issue the necessary instructions to the transaction manager to initiate and manage transactions. Those instructions often include:
A “BEGIN” instruction to initiate a transaction before locking or updating records. It is possible for a process to BEGIN multiple transactions and to associate each change/modification with a specific transaction.
A “COMMIT” instruction, which commits a transaction when a related set of database updates are complete; this will cause all database updates associated with that transaction to become permanent.
An “ABORT” instruction to terminate a transaction when it is discovered that some factor would preclude making a set of consistent database updates; this causes all updates associated with that transaction to be undone, as if they had never been made.
A “RESUME” instruction to choose between one or more active transactions, thus allowing a process to specify a particular transaction for each I/O operation.
A program that makes effective use of transactions is called a “transactional application.”
There are many existing applications are able to modify a database of one sort or another, often composed of hundreds and thousands of programs, that for one reason or another are not transactional applications; that is, they were not initially designed and prepared to include the necessary transaction instructions and programming logic to manage transactions. Nevertheless, it will be evident that such applications would certainly benefit from the use of transactions. Unfortunately the cost and risk of reprogramming these applications in order to add the necessary instructions for transaction utilization is high, often too high to justify the effort.
Furthermore, there are also transactional applications that only use transactions for a subset of the database. In many cases, it may not be desirable to use the same transaction for certain files, such as error logs, because the ABORT operation would undo updates that should be preserved. It is sometimes desirable to use transactions to manage updates to these files, but only if the transactions are managed separately from the original transactions.
Thus, there exists a need for a way to provide those applications that are without the necessary programming logic for transaction use to still be able to still be able to do so without the risk and expense of adding the necessary programming code.